Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Fix GetFPS so it doesn't hold on last time from previous window #3410

Closed
wants to merge 3 commits into from
Closed

Fix GetFPS so it doesn't hold on last time from previous window #3410

wants to merge 3 commits into from

Conversation

maksut
Copy link
Contributor

@maksut maksut commented Oct 13, 2023

Defect: GetFPS holds on to the last time value from previous windows.

In this example, second window displays the last FPS value from the first window. Until it lives longer than the first:

#include "raylib.h"

int main(void)
{
    InitWindow(800, 450, "first window");

    // Keep this window open N seconds then close it
    while (!WindowShouldClose())
    {
      BeginDrawing();
      ClearBackground(RAYWHITE);
      DrawFPS(10, 10);
      EndDrawing();
    }

    CloseWindow();

    InitWindow(800, 450, "second window");

    // Notice that DrawFPS is stuck on the last fps value from the first window
    // only after N seconds it starts drawing the correct fps
    while(!WindowShouldClose())
    {
        BeginDrawing();
        ClearBackground(RAYWHITE);
        DrawFPS(10, 10);
        EndDrawing();
    }

    CloseWindow();
    return 0;
}

The proposed fix relies on the fact that GetTime must return incremental (or same) values.

@raysan5
Copy link
Owner

raysan5 commented Oct 14, 2023

@maksut This seems to be related to a quite unexpected use case of raylib (two windows creation, one after another) but in any case, shouldn't the time measure be reseted on every InitWindow() instead of hacking the GetFPS() function?

@maksut
Copy link
Contributor Author

maksut commented Oct 14, 2023

I was trying to avoid introducing a global variable just for this "defect". Because it is a silly issue. So feel free to reject/close the PR.

FYI; I am playing with raylib & clojure where I try to livecode as much as possible. So far it has been fun. But whenever I close the window and reopen it, drawFPS gets stuck to the old value for some time. But it is not a big deal. I can just write my own getFPS, drawFPS etc.

raylib is fun! Thanks for your work.

@maksut
Copy link
Contributor Author

maksut commented Oct 14, 2023

While I was implementing my own GetFPS, I thought maybe it doesn't have to call GetTime at all.
Do you think last commit is reasonable? It solves my little problem and it might be more efficient for everybody else.

@JeffM2501
Copy link
Contributor

I'm not 100% sure this is the correct fix. The core problem is that static data is used and it doesn't get restored to the proper state when the window is reset.
The history should be cleared back to the same state as first run.
I've added PR #3445 that fully clears the static state on the first frame.

@maksut
Copy link
Contributor Author

maksut commented Oct 20, 2023

@JeffM2501 thanks for sparing some time for this.

@raysan5
Copy link
Owner

raysan5 commented Oct 23, 2023

@maksut thanks for pointing the issue and the proposed review, finally @JeffM2501 approach was merged.

@raysan5 raysan5 closed this Oct 23, 2023
@maksut maksut mentioned this pull request Nov 9, 2023
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@maksut @raysan5 @JeffM2501